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Abstract 

Goto is a simple dynamically-typed language for the 
Java Virtual Machine. Initially implemented as a 
ahead-of-time compiler to JVM bytecode, it leverages 
invokedynamic and JSR 292 method handles to imple¬ 
ment a reasonably efficient runtime. Truffle is emerg¬ 
ing as a framework for building interpreters for JVM lan¬ 
guages with self-specializing AST nodes. Combined with 
the Graal compiler, Truffle offers a simple path towards 
writing efficient interpreters while keeping the engineer¬ 
ing efforts balanced. The Golo project is interested in ex¬ 
perimenting with a Truffle interpreter in the future, as it 
would provides interesting comparison elements between 
invokedynamic versus Truffle for building a language run¬ 
time. 

1 Introduction 

Golo is a simple dynamically-typed language for the Java 
Virtual Machine ||T|. Initially designed as an experiment 
around the capabilities of the new invokedynamic JVM 
instruction that appeared in Java SE 7 El, it has since 
emerged as a language supported by a small community 
that goes beyond the bounds of academia. Applications 
have been found in Internet of Things (loT) settings, and 


we consider Golo to be small enough to be used for lan¬ 
guage and runtime experiments by researchers, students 
and hobbyists. This claim is supported by examples such 
as ConGolo, a derivative experiment for contextual pro¬ 
gramming and the community project^ Golo is cur¬ 
rently being proposed for incubation at the Eclipse Eoun- 
dation in the hope of finding new opportunities and con¬ 
tinuing the development at a vendor-neutral foundatiorj^ 

Eigure[T]provides a sample Golo program. It computes 
several Eibonacci numbers with the naive recursive defi¬ 
nition of the fib function. It takes advantage of regular 
Java executors and Golo APIs for promises and futures 
El to perform the computations on 2 worker threads, and 
collect the results through reduction of futures. 

Briefly, the main characteristics of the Golo program¬ 
ming language are the following; 

• dynamic typing using Java types, 

• higher-order functions and binding to Java single¬ 
method and functional interfaces, 

• ability to augment existing types (including from 
JVM languages) with new methods, 

*See https://github.com/dynamid/contextual-golo-lang 

^The kiss web framework is a good example: https://github. 
com/k33g/kiss 

^See https: //projects.eclipse.org/proposals/golo 
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module samples.Concurrency 

import java.util.concurrent 
import gololang.Async 

local function fib = |n| { 
if n <= 1 { 
return n 
} else { 

return fib(n - 1) + fib(n - 2) 

} 


function main = |args| { 

let executor = Executors.newFixedThreadPool(2) 
let results = [30, 34, 35, 38, 39, 40, 41, 42]: 
map(|n| -> executor: enqueue(-> fib(n)): 
map(|res| -> [n, res])) 
reduce(results, |acc, next| -> 

acc + next: get(O) + " -> " + next: get(1) + ''\n'’ 

): 

onSet(|s| -> println(''Results:\n'’ + s)): 
onFail(|e| -> e: printStackTrace()) 
executor: shutdown() 

executor: awaitTermination(120_L, TimeUnit.SECONDS()) 


# === Prints the following === 

# Results: 

# 30 -> 832040 

# 34 -> 5702887 

# 35 -> 9227465 

# 38 -> 39088169 

# 39 -> 63245986 

# 40 -> 102334155 

# 41 -> 165580141 

# 42 -> 267914296 

Figure 1: Computing Fibonacci numbers in Golo with 
concurrent and asynchronous APIs. 


• tuples and structures (augmenting the later is remi¬ 
niscent of Go-style objects El), 

• dynamic objects with instance-level definitions, 

• Python-style decorators (i.e., higher-order function- 
based). 

Unlike many other JVM languages such as JRuby, 
Jython or Nashorn, Golo is not a port of an existing lan¬ 
guage to the JVM and invokedynamic. This is interesting, 
as Golo was designed around the capabilities of invokedy¬ 
namic, which gives a different perspective on the design 
of a invokedynamic-based runtime. 

2 Ahead-of-time compilation based 
on JSR 292 

Golo uses ahead-of-time bytecode generation rather than 
interpretation. The grammar of Golo is written using 
the LL(k) JJTree / JavaCC parser generator Q, mainly 
due to its simplicity and lack of a runtime dependency, 
as it generates all the Java code required for a working 
parser. The front-end generates an abstract syntax directly 
from JJTree, which is then transformed into an intermedi¬ 
ate representation based on a Golo-specific object model, 
comprising classes to model reference lookups, functions, 
common statements and so on. The intermediate rep¬ 
resentation is visited by several phases to check for un¬ 
declared references, expand lambda functions / closures 
to anonymous functions, and ultimately generated JVM 
bytecode with the popular ASM library E). 

Stable bytecode, adaptive runtime dispatch. The 

compiler generates a largely untyped bytecode. Most 
references are on the java.lang.Object type, with 
some peculiar portions of the bytecode doing cast 
checks (e.g., branch conditions require refining to 
java. lang. Boolean and unboxing the primitive 
boolean value). The generated bytecode remains stable 
at runtime, unlike speculations and invalidations as found 
in Nashorn to try to take advantage of primitive types 
when possible. 

As most call sites (including arithmetic operators) are 
based on invokedynamic, the runtime adapts the dispatch 
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Figure 2: Operator monomorphic inline-cache based on method handles. 


targets through evolving method handle chains, based on 
types observed at runtime. Figure gives an example: 
operators use a monomorphic inline-cache construct JT). 
The construction relies on a guarded combinator that dis¬ 
patches to the right target as long as type remain stable 
(e.g., plus(Integer, Long) LongforlO + 10_L). The 
fallback branch points to a handler that dynamically finds 
a new target based on the observed types, and overwrites 
the call site method handle dispatch chain with the new 
one. 


(filter / map / reduce) 



Figure 3: Filter / Map / Reduce micro-benchmark. 


Euclidian GCD 



ms (3 forks, 5 iterations of single-shot, 20 warmup iterations of single-shot) 

Figure 4: Greatest common divisor micro-benchmark. 

Performance considerations. In general, Golo exhibits 
good performance on function and method dispatclj^ Fig¬ 
ure |3] shows the results of a micro-benchmark based on 
applying the usual filter, map and reduce operations on 
collections. Golo is practically as fast as a baseline in 
Java where the operations are implemented using collec¬ 
tion copie^ 

'*See https: //github.com/golo-lang/golo-jmh-benchmarks 
for a collection of micro-benchmarks. 

^This micro-benchmai'k was written while Golo was still compatible 
with Java SE 7, hence it would be interesting to compare with Java SE 8 
streams. 
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Figure shows a GCD micro-benchmark. While per¬ 
formance remains good compared to other dynamic lan¬ 
guages, it highlights the performance bottleneck due to 
boxing of primitive types, which is also further confirmed 
by further nano-benchmarks that we have. We are plan¬ 
ning to explore ways to be clever than we are at the mo¬ 
ment with respect to arithmetic operations. 

3 Perspectives with Truffle 

Writing an interpreter for Golo based on Truffle 13 is 
interesting for comparing the effectiveness of invokedy- 
namic versus Truffle to implement common language 
runtime patterns (e.g., arithmetic operations or inline- 
caches). In terms of performance, the following points 
are of comparison interest: 

1. functions and methods dispatch, 

2. arithmetic operations (Truffle node specialisation 
can potentially eliminate some boxings), 

3. dispatch in Golo dynamic objects (Truffle proposes 
a Shapes abstraction), 

4. statistical optimizations for application profiling 
(Truffle exposes node counters that could be use to 
mine application behavior and dynamically activate 
relevant optimizations). 

We are looking forward to experimentions with Truffle 
in the near future, and have elements of comparisons in 
the challenges of designing programming language on the 
JVM. 
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